-
Notifications
You must be signed in to change notification settings - Fork 463
Conversation
src/eosjs-jsonrpc.ts
Outdated
@@ -93,6 +96,7 @@ export class JsonRpc implements AuthorityProvider, AbiProvider { | |||
if (!response.ok) { | |||
throw new RpcError(json); | |||
} | |||
// check each return value for every action for an error and call `new RpcError`? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delete this comment
@@ -133,3 +133,8 @@ By providing that function inside `tx.associateContextFree()`, the transaction o | |||
|
|||
#### Return Values | |||
From nodeos version 2.1, the ability to receive return values from smart contracts to eosjs has been introduced. In the above examples, the `transaction` object will include the values `transaction_id` and the `processed` object. If your smart contract returns values, you will be able to find the values within the `transaction.processed.action_traces` array. The order of the `action_traces` array matches the order of actions in your transaction and within those `action_trace` objects, you can find your deserialized return value for your action in the `return_value` field. | |||
|
|||
### Read-Only Transactions | |||
Adding `readOnlyTrx` to the `transact` config will send the transaction through the `push_ro_transaction` endpoint in the `chain_api`. This endpoint will ensure that the transaction will not make any changes despite the actions in the transaction. It is typically useful for doing queries using actions but normal actions will also work with this endpoint, but they won't make changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe:
This endpoint will ensure that the transaction will not make any changes despite the actions in the transaction. It is typically useful for doing queries using actions but normal actions will also work with this endpoint, but they won't make changes.
to ->
The push_ro_transaction
endpoint does not allow the transaction to make any data changes despite the actions in the transaction. The push_ro_transaction
endpoint may also be used to call normal actions, though the actions will not make any data changes. => what if you call an action that does make changes - is this rolled back? Perhaps explicitly state what happens in this case <=
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- maybe start the ### Read-Only Transactions paragraph with:
From nodeos version 2.2, read-only queries have been introduced to eosjs. AddingreadOnlyTrx
to thetransact
config ... etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe:
This endpoint will ensure that the transaction will not make any changes despite the actions in the transaction. It is typically useful for doing queries using actions but normal actions will also work with this endpoint, but they won't make changes.
to ->
The
push_ro_transaction
endpoint does not allow the transaction to make any data changes despite the actions in the transaction. Thepush_ro_transaction
endpoint may also be used to call normal actions, though the actions will not make any data changes. => what if you call an action that does make changes - is this rolled back? Perhaps explicitly state what happens in this case <=
It is rolled back, so I changed your adjustments slightly to state that.
### Read-Only Transactions | ||
Adding `readOnlyTrx` to the `transact` config will send the transaction through the `push_ro_transaction` endpoint in the `chain_api`. This endpoint will ensure that the transaction will not make any changes despite the actions in the transaction. It is typically useful for doing queries using actions but normal actions will also work with this endpoint, but they won't make changes. | ||
|
||
Adding `returnFailureTraces` to the `transact` config will return a trace of the failure if your transaction fails. At this time, this is only available for read-only transactions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe:
Adding returnFailureTraces
to the transact
config will return a trace of the failure if your transaction fails. At this time, this is only available for read-only transactions.
to =>
Adding returnFailureTraces
to the transact
config enables the return of a trace message if your transaction fails. At this time, this is only available for read-only transactions. => what happens if you add this to a push_ro_transaction that is calling a non read only action - is nothing returned?.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed your changes slightly to state that it is only available for the push_ro_transaction
endpoint.
docs/troubleshooting/02_rpcerror.md
Outdated
@@ -0,0 +1,72 @@ | |||
When a call to the chain_api is performed and fails, it will result in an RPCError object being generated to inform why the transaction failed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe:
When a call to the chain_api is performed and fails, it will result in an RPCError object being generated to inform why the transaction failed.
to =>
When a call to the chain_api is performed and fails, it will result in an RPCError object being generated which contains information on why the transaction failed.
docs/troubleshooting/02_rpcerror.md
Outdated
@@ -0,0 +1,72 @@ | |||
When a call to the chain_api is performed and fails, it will result in an RPCError object being generated to inform why the transaction failed. | |||
|
|||
The RPCError object will error with the concise message, for instance 'Invalid transaction', but additional details can be found in both the `details` field and the `json` field. The `json` field holds the entire json response from `nodeos` while the `details` field specifically holds the error object in the `json`. This is typically in different places of the `json` depending on what endpoint is used in `nodeos` so the `details` field is available to quickly see the error information without needing to search through the `json` object. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe
The RPCError object will error with the concise message, for instance 'Invalid transaction', but additional details can be found in both the details
field and the json
field. The json
field holds the entire json response from nodeos
while the details
field specifically holds the error object in the json
. This is typically in different places of the json
depending on what endpoint is used in nodeos
so the details
field is available to quickly see the error information without needing to search through the json
object.
to =>
The RPCError object will contain a concise error message, for instance 'Invalid transaction'. However additional details can be found in the details
field and the json
field. The json
field holds the complete json response from nodeos
. The details
field specifically holds the error object in the json
field. The data content of the json
and ``detailsvary depending on the endpoint is used to call
nodeos`. Use the `details` field to quickly find error information.
docs/troubleshooting/02_rpcerror.md
Outdated
|
||
The RPCError object will error with the concise message, for instance 'Invalid transaction', but additional details can be found in both the `details` field and the `json` field. The `json` field holds the entire json response from `nodeos` while the `details` field specifically holds the error object in the `json`. This is typically in different places of the `json` depending on what endpoint is used in `nodeos` so the `details` field is available to quickly see the error information without needing to search through the `json` object. | ||
|
||
As you can see below, the concise error message might not give enough information to really discern the issue. While the error has `eosio_assert_message assertion failure` as the concise error, in the `details` field the `overdrawn balance` error mentioned. It's important to note that the format of the `details` object can be different depending on what endpoint is used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe
As you can see below, the concise error message might not give enough information to really discern the issue. While the error has eosio_assert_message assertion failure
as the concise error, in the details
field the overdrawn balance
error mentioned. It's important to note that the format of the details
object can be different depending on what endpoint is used.
to =>
In the details
and json
examples below, you can see that the error message may not contain enough information to discern what caused the action to fail. The error message contains eosio_assert_message assertion failure
. Looking further at the details
you can see an overdrawn balance
message.
It's important to note that the format of the details
object can be different depending on what endpoint is used. => removed this bit as it is mentioned above. If you wanted to emphasise (or I have misunderstood) pwerhaps
=> Please note that the format of the details
object will differ dependant on which endpoint is used.
=> as an additional thing - I think you choose the endpoint with the readOnlyTrx flag, is it worth mentioning the other endpoint explicitly and/or showing an example from calls to both endpoints -assuming there are two endpoints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a large amount of different responses from nodeos, unfortunately it won't be easy to state all of them.
CI/CD changes for PRs #937/#963/#964 - merging per a request from Brad this is a bug with github actions, version 12.14.1 has been replaced by the v15.14.0 ones, can you override and merge it? It also might be because I have to copy the workflow files to master but I won't be certain until this one is merged Will be verified and can be reverted if something else breaks.
Change Description
Adds support for Read Only Transactions and the return failure traces option (exclusive to read only transactions for now). Additionally changes the RPCError object to include a
details
variable that includes the error object for responses.API Changes
transact
optionreadOnlyTrx
transact
optionreturnFailureTraces
Documentation Additions
Section about read only transactions,
returnFailureTraces
, and a new page aboutRPCError